This invention relates generally to software component interfaces, and more specifically to providing binding options for software component interfaces.
Software components are a technique used to improve software development productivity and program flexibility. Reusable software components are designed to apply the power and benefit of reusable, interchangeable parts from other industries to the field of software development. Software components have standard interfaces making them interchangeable and reusable. Examples of software components tend to be oriented toward user interface elements. They can be simple like familiar push buttons, text fields list boxes, scrollbars and dialogs, or they can be more complex, such as calculators and spreadsheets.
Microsoft""s COM (Component Object Model) is an example of a software component development model. COM is a component environment commonly used by applications written in Microsoft""s Visual Basic and Visual C++ programming languages. COM can generally be defined as a specification for a software development methodology and an Application Program Interface (API) that allows software components to communicate and interact with each other, and to be dynamically interchanged. A detailed description of COM methods and other aspects of COM are described in Dale Rogerson, xe2x80x9cInside COM,xe2x80x9d 1997 (ISBN 1-57321-349-8) which is hereby incorporated by reference.
COM requires that software components, which are also referred to as COM objects, use certain standards and rules when defining the APIs that they expose to other components that they communicate with. The APIs they expose define the communication contract between components. An API that is exposed by a COM object is referred to as a COM interface. A programmer can use a published definition of a COM object and an interface it exposes to write programs that will use these objects by calling functions that are defined by the interface definition. The interfaces that are exposed by an object can be one of three different types: custom interfaces, dispatch interfaces and dual interfaces.
A custom interface requires the programmer calling the interface""s methods to have the description of the interface at the time of the implementation. The calls made to the interface methods on custom interfaces are referred to as early bound calls. This is because the choice of which method to call occurs at the time the method is invoked. Interfaces of this type are derived from the common IUnknown interface definition.
A dispatch interface (dispinterface) hides the details of an interface implementation from the application programmer who is using it. Every method in a dispatch interface has an identification number that is referred to as a DISPID (dispatch identifier). The programmer prepares the code to call certain methods that are common for all dispatch interfaces, and passes the DISPID of the method to execute it. The programmer can also call other methods to convert method names that might be available in the program to DISPID values. The calls that are made to the methods on dispatch interfaces are referred to as late bound calls. This is because the choice of the particular method to call is made by the dispatch interface after the method has been invoked. A dispatch interface cannot be called using early bound calls. These interfaces are derived from the common IDispatch interface definition, which is derived from IUnknown interface definition.
A dual interface is an interface that is derived from a dispatch interface, but its methods can also be called using early bound calls.
COM components have the quality that when used within their intended environments, new or alternative components can be substituted for old components without requiring any changes to the application using the component. In addition, software components can be easily incorporated into new programs using software building tools, thereby freeing the developer from writing code to implement the functionality provided by the component.
The above described qualities provide significant advantages over other models for software development, however there are also several drawbacks.
First, a COM object exposes one or more interfaces with multiple methods on each. On larger components, the number of interfaces exposed and the number of methods on each interface may be overwhelming. This in turn results in a large number of test scenarios. The total number of test scenarios is directly related to the number of interfaces and methods, since each interface and method define different ways of using the component.
Second, as discussed above, an interface may be one of three types. The dual interfaces in particular require their methods to be tested both using the IDispatch interface approach and the custom interface approach. This causes the number of test scenarios to increase by at least a factor of two for dual interfaces.
Third, implementation of test cases requires different coding techniques for early bound and late bound interface calls. This can typically double the amount of test code to be written, with a corresponding increase in the time spent preparing and debugging the test cases.
For early bound cases in particular, there is also the overhead of rebuilding the code when the interface definition changes. Although typically an interface definition does not change once it is public, it can be modified during the implementation. With each change to the interface definition, all software modules that contain early bound calls to the interface must be rebuilt. This takes time, complicates the development process and requires the test group to have access to the detailed information about the interface definition at all times in order to be aware of any changes and rebuild the test code.
Finally, there is the problem of user education. COM can be a rather complicated area of software technology, and it takes a developer time to learn its details and intricacies. If the test scenarios are to be implemented using a conventional programming language, the developer has to be fluent using this programming language as well. This takes time and is an extra cost. In addition, there is a risk of having bugs in the test suite code, since it too is a complicated piece of code.
Therefore, there is a need for a component with a minimal number of easy to use interfaces that allow for the use of both early and late bound calls. In addition, the component needs to provide a choice of which type of call to be made at run-time. Finally, the applications using the component should not need to be recompiled and relinked and when an interface changes.
The above-mentioned shortcomings, disadvantages and problems are addressed by the present invention, which will be understood by reading and studying the following specification. The invention describes a component environment providing dispatch proxies and object proxies. In one embodiment of the invention, the computerized system includes an operating system supporting component interfaces. In addition, the system includes a first interface to a target component, with the first interface having an early bound method. The system further includes a second interface to a proxy component, with the second interface having a late bound method. Also included in the system is a dispatch proxy operative to invoke the early bound method of the first interface from an invocation of the late bound method of the second interface.
Thus, in one embodiment of the invention, a proxy component exposes a simple dual interface that contains methods and properties that can be accessed by its host application. An application can call these methods to create COM objects and ask for additional interface implementations from them. The methods are named after the actual COM library functions that are used in C/C++ programs, however those in the art will recognize that other alternative names are possible.
The proxy component provides its host with the ability to create other COM objects, query for interfaces that are implemented by those objects, make early or late bound calls to those interfaces, and store additional COM objects that may be created as a result of these calls. The host only has to be able to communicate to the interfaces that are exposed by the proxy component thereby providing a generic communications capability for any interface.
In an alternative embodiment of the invention, the proxy component exposes a property, referred to as xe2x80x9cForceProxyxe2x80x9d, through its main IDispatch interface. If this property is set to TRUE, then the following calls made to the COM objects that are created and communicated using the proxy component are made as early bound calls. If this property is set to FALSE, the calls are made as late bound calls. If an interface that is being communicated to is a custom interface then the ForceProxy property settings do not change anything and the calls are always made as early bound calls.
In addition, a computer system that hosts a proxy component can also host a script engine, allowing the complete COM functionality to be carried into a script language environment by using an embodiment of the invention. Since a script does not need building and is interpreted at run-time, proxy components provide on-the-fly access to COM objects and their interfaces to a script environment. This is the functionality that a programmer would have if the program were being written in a conventional programming language such as C++. However, unlike a C/C++ program a script program does not need to be compiled and linked to get an executable as a result.
The dispatch proxy and object proxy described in the present invention provide for advantages not found in previous systems. First, dispatch proxies have relatively few interface methods, thereby simplifying the programming knowledge required to use a proxy component. The low number of interface methods also reduces the amount of interface testing that is required.
Second, testing is simplified since the interface allows for choices to be made at run-time about which type of target component interface to call. This on-the-fly calling method defining ability reduces the possible number of test cases at least by a factor of two. Since the host can set or reset this flag before starting to run a test case, the complete test suite can be run using early or late bound calls, without actually changing the test suite. In addition, use of a proxy component reduces the room for error when creating test code, since the test code will look very similar regardless of the interface and object that is being tested. Also, since the test cases can be written using commonly known and easy to learn script languages, the learning and implementation times are much smaller than C/C++ coding cycles. For example, the JavaScript script language could be used to write COM based programs.
Third, the host application does not need to be rebuilt when changes in the target component interface occur. The proxy component of the present invention acts as a wrapper around the objects and interfaces that are created and communicated by the host. This results in simplified maintenance.
Fourth, dispatch proxies provide for generic communication to the host, when communicating to other COM objects. This way, the host application only needs to know the names of the methods and their parameters. There is no need to write separate code pieces for early and late bound calls. This simplifies and supports implementation.
Fifth, the proxy component of the present invention also wraps the objects that are returned from the calls that are made to other COM object""s interface methods. Since the communication technique is the same for these objects as well, the proxy component provides simplified integration. This is especially true for the use of the proxy component with a script engine.
Finally, use of the proxy component of the present invention reduces the complexity of the COM software development task and decreases the time to be spent learning the details of the COM technology. Since the overhead is less, productivity increases. This is especially true when a computer system that hosts a script engine uses a proxy component.